When myriad developers create applications, visual verification tests of these applications is typically time consuming and resource intensive due to the need for human confirmation of test results falling outside of specified parameters. For example, when a developer submits a new graphics card driver, user-mode test programs rely on comparison of master images to output from the driver to test the driver. When the user-mode test program identifies a divergence from the master image, the user-mode test program files a bug report, and human intervention is required to address the bug.
In many cases, the divergences do not actually represent problems, but instead represent false positive reports of bugs due to round off errors, hardware differences, or non-human-perceptible color changes introduced by the new driver. Nevertheless, a human has to review the output to determine whether a problem actually exists due to the new driver, which is expensive in terms of dollar-cost and time.
Desktop Window Manager (DWM) is part of the Windows™ operating system and is a full screen DirectX™ application that takes advantage of hardware acceleration and includes a desktop compositor and a window manager. The window manager takes care of window operations such as scrolling, resizing, moving, minimizing, maximizing and so on. The window manager also enables different window types such as layered windows, popup windows and so on.
When DWM is running, applications do not draw directly to the video memory but to an off-screen buffer, called a surface. The desktop compositor then takes surfaces for all the applications running on Windows, composes the entire desktop and renders using DirectX™ runtime. The compositor uses various primitives to render different parts of the desktop. It represents parts of each window such as client area, buttons, title bar and so on using a two-dimensional (2D) mesh. The actual mesh used by the compositor is complex to render effects such as rounded corners and shadows, and the mesh is textured using bitmaps. These bitmaps can be off-screen surfaces drawn by the application or parts of the theme texture. For example, the non-client area of the windows that are part of the composited desktop can be rendered to present a glass-like or other textured appearance. The superbar, which can enclose the address bar and the navigation buttons, can also be rendered to present the glass-like or other textured appearance. The compositor also uses a solid color brush. For example, a semi-transparent black brush can be used to dim the wallpaper.
In addition, various visualization elements, including composition and rendering primitives as exposed by DWMCore.dll, are not accessible via the Desktop Window Manager (DWM) API surface to consume in a user mode test suite. Such primitives often have complicated semantics, and validation of the primitives' behavior is problematic. DWMCore.dll and its precursor MILCore.dll represent examples of dynamic linked libraries that a desktop compositor uses to create user interface graphics.
The difficulties in testing primitives are exacerbated due to the large number of primitives, and because they can be arbitrarily arranged, this leads to a combinatorial explosion of possible test scenarios. In addition, not every test scenario is useful for each composition, and there is little indication of which of the possible test scenarios will be useful. Traditionally, validating the rendering of primitives requires a previously created database of master images against which the test is run. These master images must be refreshed frequently, and differences during validation due to floating point errors often lead to false indications of failure.